56 kbps modems are now standardized in accordance with the ITU V.90 Recommendation. However, many 56 kbps modems, particularly end user modems, may only be compatible with legacy modes such as K56flex, V.34, V.FC, and V.32. Such legacy modems, and downwardly compatible V.90 modems, may have an undesirably long connect or initialization time between dial-up and full rate data mode. The startup time can be up to 30 seconds, which can be rather annoying and unattractive from the perspective of the end user, especially in light of other data communication protocols that appear to operate in an “always connected” manner.
V.90 modems that support legacy modem protocols typically perform the functions shown in Table 1 during initialization. The time periods associated with the operations set forth in Table 1 may vary from connection to connection depending upon various factors such as the server speed and channel conditions.
TABLE 1Conventional V.90 Modem StartupPROTOCOLOPERATIONTIME (seconds)—Dialing1—Call Establishment1V.8bisCapabilities3.5ExchangeV.8Capabilities3.5ExchangeV.90 Phase 2Probing & Ranging1.5V.90 Phase 3Digital Impairment8.5Learning; InitialAPCM TrainingV.90 Phase 4Final APCM2.5Training; Set PowerLevels; ConstellationTransmissionV.42/V.42bisError Correction;0.5Data Compression—Login0.5-5TOTAL = 22.5-27.0
The V.8bis operation includes a relatively long timeout period that encompasses much of the time period associated with the operation. This operation is described in detail in ITU-T Recommendation V.8bis (International Telecommunication Union, August 1996), the content of which is incorporated by reference herein. The V.8bis protocol is an extension of the V.8 protocol, as described in ITU-T Recommendation V.8 (International Telecommunication Union, February 1998), the content of which is incorporated by reference herein. In accordance with V.8bis and/or V.8, the two modem devices exchange their individual capabilities such that compatible protocols may be utilized during subsequent initialization and data communication procedures.
The various V.90 startup phases are utilized to determine the analog and digital channel characteristics, to train the modem equalizers, and to otherwise attempt to optimize the current communication session. The details of the V.90 startup phases and other aspects of a V.90 modem system may be found in ITU-T Recommendation V.90 (International Telecommunication Union, September 1998), the content of which is incorporated by reference herein. Although a portion of the V.90 startup segments shown in Table 1 are required without regard to the location or status of the client modem, many of the operations could be eliminated or shortened upon repeated connections associated with the same (or nearly identical) channel characteristics.
In a conventional V.90 modem system, error correction and data compression techniques are performed during the V.42/V.42bis stage. The specifics of V.42 are contained in ITU-T Recommendation V.42 (International Telecommunication Union, October 1996), the content of which is incorporated by reference herein. The specifics of V.42bis are contained in ITU-T Recommendation V.42bis (International Telecommunication Union, January 1990), the content of which is incorporated by reference herein. The V.42 operation is desirable such that the modem system can perform the login procedure in a substantially “error free” mode. The login procedure may be conducted with CHAP and PAP protocols; both are utilized for security purposes in the context of point-to-point protocol (“PPP”) connections, e.g., a connection between a client computer and an internet service provider server. From the perspective of the V.90 modem devices, the login information is transmitted as data. Once the login procedure is performed, the dial-up connection is complete and data may be transmitted between the server and the host software associated with the client.
The widespread use of the internet as a daily research, entertainment, and communication tool has increased the deployment of 56 kbps modems. However, many channels can only support legacy modes such as V.34. Thus, although most newer modems (particularly those sold with new personal computers) are compatible with the V.90 Recommendation, many legacy modes are still in use. The long initialization period associated with V.90 modems that fall back into legacy modes may be annoying and undesirable in many applications and can be a serious hindrance where a user would like to establish an immediate connection after an unanticipated disconnect. In addition, even in the context of a connection between two V.90 modem devices, the long V.90 startup phases may test the mettle of an impatient end user. Accordingly, it would be highly desirable to reduce the initialization time normally associated with a conventional V.90 modem system.
A given modem communication session may be interrupted or disconnected for any number of reasons. For example, a call waiting signal may disrupt a modem connection to the extent that the modem call must either be reconnected or reinitialized. As another example, it may be possible to place a current modem connection on hold to enable the user to answer an incoming call in response to a call waiting signal or to enable the user to place an outgoing call without disconnecting the modem connection. Ideally, the modem connection could be re-established in an instantaneous manner. However, in a practical system, a retraining or reinitialization procedure must be carried out to ensure that the two end devices are properly synchronized and to ensure that the channel is adequately equalized. As discussed above, conventional V.90 modem systems may spend more than 20 seconds during such retraining and reinitialization. Accordingly, it would also be desirable to reduce the reconnection time between the same modem devices in response to a temporary disconnect or a temporary pause in the data communication.
One major time consuming portion of modem training and negotiation occurs during parameter exchanges, such as exchange of data signaling rate, preceding coefficient, spectral shaping, constellation information and etc. With reference to FIG. 5, it is shown that, for example, during V.90 negotiations, an analog pulse code modulation (“APCM”) modem 580 transmits a constellation parameter (“CP”) frame 510 to a digital pulse code modulation (“DPSM”) modem 590 that, in exchange, transmits a modulation parameter (“MP”) frame 520 to the APCM modem 580. The MP frame 520 and the CP frame 510 are in synchronous form and include many bits of information and CRC information for error checking purposes (see FIGS. 17 and 18), as further described below.
As shown in FIG. 5, the APCM modem 580 continuously transmits CP frames 510 to the DPCM modem 590 until the APCM modem 580 receives a receipt acknowledgement from the DPCM modem 590 for one of the transmitted CP frames 510. Similarly, the DPCM modem 590 continuously transmits MP frames 520 to the APCM modem 580 until the DPCM modem 590 receives a receipt acknowledgement from the APCM modem 580 for one of the transmitted MP frames 520.
The receipt acknowledgement for the CP frame 510 is transmitted in the form of an MP frame 520, including each and every bit of information and having the acknowledgement bit 33 of the MP frame 520 set to a “1”. The MP frame 520 having its acknowledgement bit 33 set to a “1” is denoted as MP′ frame 522. Once the DPCM modem 590 receives a CP frame 510, the DPCM modem 590 starts transmitting the MP′ frames 522 instead of the MP frames 520. This repeated transmission of MP′ frames 522 continues until the DPCM modem 590 receives a receipt acknowledgement for the MP or MP′ frames 520 or 522.
Similar to the DPCM modem 590, the receipt acknowledgement from the APCM modem 580 is transmitted in the form of a CP frame 510, including each and every bit of information and having the acknowledgement bit 33 of the CP frame 510 set to a “1”. The CP frame 510 having its acknowledgement bit 33 set to a “1” is denoted as CP′ frame 512. Once the APCM modem 580 receives an MP frame 520, the APCM modem 580 starts transmitting the CP′ frames 512 instead of the CP frames 510. This repeated transmission of CP′ frames 512 continues until the APCM modem 580 receives a receipt acknowledgement for the CP or CP′ frames 510 or 512.
The repeated transmissions of these long CP, CP′, MP and MP′ frames, including many bits of information, are indeed a tremendous overhead. This problem, however, gets even more exuberated in the next generation of standards, such as the ITU V.92 Recommendation, as more parameters and bits of information must be exchanged between the modems. FIG. 19 shows an example of the V.92 constellation parameter frame for the APCM modem 580 referred to as CPa frame 1900. As seen, the CPa frame includes many more bits of information than the CP and MP frames 1800 and 1900 (see FIGS. 17, 18 and 19), such as the constellation information with high resolution as well as precoder and prefilter coefficients. The CPa frame 1900 further includes variable length parameters, such as parameter 1920, that can potentially add many more bits of information to the CPa frame 1900.
Concerns have been raised that because of the acknowledgement mechanism introduced in the ITU Recommendation V.34 and re-used in the ITU Recommendation V.90, the startup time may be unduly increased for the ITU Recommendation V.92, due to these long sequences. For example, during a V.92 PCM upstream startup, a significant amount of information needs to be exchanged between the DPCM modem 590 and the APCM modems 580. In particular, the DPCM modem 590 needs to transmit very long sequences, including constellation information with high resolution as well as precoder and prefilter coefficients in the CPa frames.
Accordingly, there is an intense need in the art to eliminate the tremendous overhead of repeatedly transmitting these very long sequences, including many parameters and bits of information, thereby reducing the training and negotiation time and achieving a quick connect.